>>78540416
damn these threads are still going on? I applaud the anons who continue these threads.

>>78540424
They got winlogon to work, actually.

There's a fuck ton of driver issues resulting in us needing to get them from the ISO. Would it be possible to just not require them? Most of this is going into VMs anyway, so couldn't we just use generic drivers instead? Sort of a TempleOS type deal, with no USB or graphics acceleration or anything.

>>78540502
What's the point of this project if you can't even make the system half as usable as the original?
You could work on ReactOS, Haiku, anything actually if your plan is not to make it usable, that way the work would at least be meaningful.

>>78540547
>What's the point of this project?
It's fun.

>>78540570
If you say so.

I don't believe it winlogon works good job lads

>>78540416
>https://wopen3qf3trpihet.onion
Doesn't work for me.

>>78540836
see >>78511625

>>78540867
I was the one who asked in that thread, OP should probably stop posting the dead link.

3>Compiling - winlogon\daytona\jobwait.c for i386
3>Compiling - winlogon\daytona\samwait.c for i386
3>Compiling - winlogon\daytona\shutinit.c for i386
3>Compiling - winlogon\daytona\nddeagnt.c for i386
3>Compiling - winlogon\daytona\generating code... for i386
3>winlogon\wlx.c(278) : error C4700: local variable 'Status' used without having been initialized
3>Compiling - winlogon\daytona\os2ssmig.c for i386
3>Compiling - winlogon\daytona\os2ssrtl.c for i386
3>Compiling - winlogon\daytona\generating code... for i386
3>Compiling - winlogon\daytona\contextactivation.cpp for i386

Do I need to turn off -Werror?

>>78541186
no you we mast be ablo to compile without that check. That is an error, why we not init the variable lol?

>>78540416
How are XP-tan's jugs so fucking BIG?

>>78541521
Someone drew them big, retard.

>>78541386

if (!NT_SUCCESS(LsaRegisterLogonProcess(&asProcessName, &LsaHandle, &SecurityMode))) {
// TODO: obfuscation here
DebugLog((DEB_ERROR, "LsaRegisterLogonProcess failed: %#x\n", Status));
return FALSE;
}

probably originally something in the obfuscated code block had Status written first.

>>78541618
so we have a bug ahah. that value whatever it is I guess is important to set ahah

Bump

>>78542071
bump

>>78542735
bumperino

>>78540443
based

>>78540416
Let me know when you make a Friendly MS-DOS thread. That was the shit back in the day.

To winlogon anon, Tester Anon here,
I just norticed you can invoke logonui by typing logonui.exe at the command prompt.

Unfortunately logonui is a little flaky when ran this way and will not log you in.

Also notices we have source to logon ui in the XPSP1 tree at: windows\advcore\duser\directui\test

Hey anons I talked to a lawyer recently about the leaks discussing in detail just how much source was leaked and asking if there was anything we could do to legally take advantage of this and he said there is a potential especially if we make sure this checks legally out we could argue in the courts that windows XP/2003 can no longer be protected under copyright law and that we could force M$haft to make all the xp/2003 sauce public domain, I'd say depending on how the other leaks check out(didn't ask about those) we might can also file claims for other parts of windows such as a case based on the research kernel leak, should seriously start seeing if this legally checks out and file suit accordingly if we have an actual case

>>78544322
bullshit

>>78540547
>work on ReactOS
Let it go Jim. They're incompetent and their project exists only to get donations from "anonymous" donators such as Samsung.

I'm serious he wasn't willing to talk at length since I wasn't technically paying for services at the time planning on making an appointment soon since he invited me so we can talk at length and make sure will let you guys know what he says

bump

Hi, newfag here. Help please!!

Please tell me how to get either a secure, updated windows 7, but preferably XP.

OR BOTH

PLEASE IM SO TIRED OF W10 LINUX IS SO BROKEN TOO :(

My hardware is skylake, early skylake w/ xp support but I can downgrade if needed.


btw... does xp pae support work??

>>78545171
If you cant make Linux work you probably can't setup XP or 7 for current use

>>78545171
Wrong thread, this is for the leaked source code of Windows XP/Server 2003 and working towards making it somewhat usable.
>newfag here
It shows, lurk more.
See >>>/g/sqt/

>>78545171
https://www.are.na/the-curator/windows-xp

>>78545282
you probably have no idea yourself
i make linux work fine it's just garbage

what a bunch of dumbasses

>>78544322
All M$ would need to do is splash the cash in the right direction, and their legal team would devistate any opposition.. As their Source code licensing isn't under GPL we wouldn't have a leg to stand on, this code is legally restricted, and because they have their Source Code scheme for Governments etc to access their code that would make it even more difficult to challenge M$

>>78545171
What A wank stain

>>78545171
>>78545587
I nearly had a stroke whilst attempting to read this shit. Learn English, retard.

I applaud the anons doing this and I congratulate them for getting compilation and winlogon to work, but could someone explain what winlogon does and how it was broken to a layman?

I get it handles user logon but I thought anons had already logged on in the compiled windows 2003 versions?

>>78540416
A world without walls and fences needs neither Windows nor Gates

>>78545806
Mindlessly parroting freetard nonsense doesn't make your hobby OS usable.

bump

Bump

LoL based NTDEV is still getting shit taken down after so long, this time his screenshots on his Twitter LOL

https://twitter.com/NTDEV_/status/1324327120412303362?s=19

>>78547070
Razvan FagLord wanted the attention. Now he got all the attention he wanted from Microsoft.

>>78547340
The fact that his user handle is NTDEV is highly unoriginal it annoys my autistic ass.. Especially because it's the name of a build group at MS Internal

>>78545775
the problem was that winlogon source wasn't included in the leak, so people tried to use windows 2000 leak winlogon / binaries from other versions

obviously that wasn't gonna work out of the box since the two are different in important ways, and anons managed to tweak it so it worked the way the win2k3 leak expected it to

for a more technical answer, wait for someone who actually worked on it lol

Are we able to change release type (e.g from fre to chk) without reloading razzle?

For example: in the XboxNT src, once the build env is loaded, we can switch release type

>>78547496
The build type and output dirs are set variables passed by razzle, changing those may solve my question

>>78541186
>>78541386
>>78541618
>>78541697
Yeah that's a weird error, I didn't get it when I was tested it out before packaging into the ZIP, but cleanbuilding afterward made it show up.

Fixed version here:
>winlogon200X_v2d.zip
https://gofile.io/d/jfk3js

>>78545775
winlogon handles user logon, and in winxp/2003 also handles a lot of WPA activation related shit.
Previously we got around not having source code by using the pre-built winlogon.exe that was included with the released server2003, but that wasn't ideal since we can't modify it, and it also made our builds subject to WPA crap too.
For a while (since near the leak first happened) we've had win2000-era source code for winlogon which kinda worked but not fully, only a few days ago we finally got that source code fixed up enough so we can actually log in with it
There's still some issues though and missing features like fast user-switching, adding those isn't too difficult though, just very time consuming

>>78548024
Are you going to add fast user switching?
What else does it miss?

>>78548082
Probably gonna try fixing the other issues like login-scripts not running/amd64 support/etc first, adding features like user-switching will probably take a while

I'm not really sure what else exactly is missing, afaik there's some differences with screensaver support, and maybe remote-logins too
Not stuff that most people here would really care about, but it'd be nice to get our code to match win2003 binary eventually.. maybe in like 3 years or something lel

>>78544079
Have you tried running the per/pro SKUs? those should use logonui directly.
I think there's a registry/GP thing to enable that ui on server too, can't remember tho.

>>78548024
>>78547491
thanks
Damn I didn't realise there were parts missing to the leak
I thought it was the full source

>>78548203
Where would be best to start for a novice to learn the basics, to end up being able to help with this kind of thing?

>>78544526
>They're incompetent and their project exists only to get donations from "anonymous" donators such as Samsung.
Maybe they're not that useless as it may seem.
They're even hiring full time now with the aim of improving the stability of some system components, there are GSoC contributions, etc.
They just have to make some better community guidelines to prevent their community from being toxic and they should be fine.
They even partially listened to this Russian hacker https://swapcontext.blogspot.com/2019/12/is-reactos-great-again-2019.html
that is they ported a syscall fuzzer to their system and they seem to deal with some old regressions, see the list of fixed things for 0.4.14 release:
https://reactos.org/wiki/Tests_for_0.4.14

>>78548241
My own advice about starting off would probably be to take a disassembler like IDA Pro/Ghidra and use it to study compiled output of some source you have, eg. maybe compile >>78547930, then use disassembler on the result winlogon.exe, and compare the disassembly it gives with the source code you have.
There is a near 1:1 correlation between them, aside from some things like compiler optimizations, if you study it enough you should be able to see things like how function calls are translated from the source into the compiled binary, how structures are populated, etc.
Really though you need a good knowledge of the source language (C in this case) if you want to start decompiling things back into it.

This is probably awful advice for starting RE in general though, this is more toward decompilation, for starting RE there's a lot of info about learning IDA/Ghidra out there.

>>78548203
I have the new winlogon ran under pro SKU. A minimized CMD window appeared along with the logonui, and soon after I login the CMD window disappeared. Seemed there is no errors

>>78548203
BTW, even if I don't use any anti-WPA tool, the "30 days to activate" taskbar notification doesn't appear with the new winlogon.
I don't know whether WPA is still there or not.

Bump

>>78548692
I think most of the WPA stuff is inside winlogon so hopefully not, maybe changing system date can see if it triggers?

bump for sp3 source code (or posready 2009)

bumpo

>>78545587
Bro, just go to the catalogue and look for the old threads. Check out how many times shit like that gets asked, it gets old.
The OP has a FAQ, you have to fucking compile and cobble it all together at this point, we're not at the "usage" stage.

>>78544079
We have the source for logonui.exe as logondui inside shell\ext\logondui
Should be in both server2003 & XPSP1 trees.

I tried looking for some way to enable it under server2003 and the only solutions I found were using tweakNT to change product edition - I guess now we have the full source we can maybe remove all the crap that checks this instead though.
I'm still not sure what actually launches logonui instead of winlogon/msgina though.

>>78540416
Friendly bump.

>>78549683
Better idea since that ain't happening: browse through CVEs and patch them all one-by-one

>>78550500
if you build pro sku server 2003 logonui works.
it's only disabled for server sku because you can't select reboot/shutdown reason in logonui

>>78551590
Hm, pretty sure there's a group policy thing to get rid of shutdown reasons, I'm like 99% sure that was one of the mods the old server2003 workstation guides used to have

>>78550500
With the now working built winlogon, logonui never fires up under the pro sku. There's still that RPC error on amd64 sp1 as well.

>>78552080
Also if you logon using the latest built winlogon, and send ctrl+alt+del and do a 'disconnect' you get logged off and if you try to log back in or reconnect the 'disconnected' session through taskmgr you can't do that for whatever reason.

>>78552080
Hm, how come the other anon had it working fine then? >>78548654
Guess I'll have to see what windbg says about pro SKU

>>78552117
Yeah there's a lot of new code related to "reconnecting" in the XP winlogon, only implemented a tiny bit of that, but guessing that's related.
I wasn't sure how I could actually test that stuff out but now I know

>>78552141
Let me try v2d - maybe that is why

Guide should maybe mention >>78068378
Though I don't think anyone has updated that originated-from-NT4 codebase to match any changes in win2003 yet though
Maybe a fun exercise for someone here? you only need BinDiff & IDA/Ghidra, pdb files will give you function names for free, BinDiff will tell you which functions you need to focus on.

>>78552141
Yeah, the windows 2000 style logon dialog and a command prompt loads and works but the directx based logondui (logonui.exe) does not load and work on x86 fre.

How did you fix the loaduserprofile RPC call error on 32 bit? - I suspect that whatever was done for that needs to also be put in a different spot for amd64 sp1 logon to work.

>>78552182
btw for any winlogon hackers here, I found antiwpa 2.2 has a tool that can patch winlogon.exe to remove the checkers & encryption code from the EXE, should make reversing it a lot easier, but I'm not sure if there's anything like this for the amd64 winlogon

Though IMO the disassembled winlogon.exe code anon posted last thread is probably a much better resource for reversing from, not having the checker code at all should hopefully help with function matching etc. The file structure in that code is pretty nice too.

>>78552302
winlogon was missing a call to userenv.dll!InitializeUserProfile, which was needed for userenv to know that it's a local (aka console) logon, it only tries using RPC server for logon if it's a remote login, local logins use a different codepath.

Maybe something is going wrong with this process in amd64, or some additional checks were added in the sp1 userenv.dll, or hell maybe amd64 solely uses RPC server for logins?
I'm still not sure what RPC server it's meant to be using, at least I didn't see anything in winlogon for initialising one.

>>78552364
>I'm still not sure what RPC server it's meant to be using, at least I didn't see anything in winlogon for initialising one.
Also I think I saw something about the RPC server being provided in the login request though, which makes me think it's 100% only meant for remote-logon related things, doubtful amd64 would change things so local logins need it too, but who knows.

>>78552389
From what I can tell in the event logs it was broken on x86 too and got fixed when you finally got the ability to logon but on amd64 sp1 it is still broken per the system event logs and that dialog re-draw behaviour still occurs.

>>78552415
Seems like some named pipe or something is not being initialized for fast user switching / the task manager 'disconnect' option. (login as user1, fire up task manager go to users and click disconnect, land at logon dialog, login as user 2, repeat above, this time selecting the other user in task manager and clicking connect. get an error about "the system cannot find the file specified, disconnect again and try to logon again and you'll get that same error dialog this time after the logon dialog.

File: file.png (70 KB, 1226x711)

70 KB PNG

>>78552415
Yeah it's fixed because now it doesn't bother with RPC at all, in x86 at least, because now that userenv knows it's local login it uses a different codepath.

Eg. in pic related, the top path used to be skipped because IsConsoleWinlogon returned false, and it used bottom path instead which did RPC shit, but calling InitializeUserProfile fixes that and afaik it's using the top path instead now.

Maybe something is going wrong with amd64 and IsConsoleWinlogon is still returning false, or maybe in amd64 it only has the RPC server route, not sure. I'll probably pick up userenv.dll/pdb and take a look later, see if IsConsoleWinlogon has any new conditions.

File: file.png (19 KB, 1063x225)

19 KB PNG

>>78552474
Just below where I screencapped in the bottom path is this code, which is what fails with the RPC error.
Could be that amd64 is always using this code no matter what IsConsoleWinlogon is returning, and somehow we're meant to start the COM server that it's trying to talk to, but I didn't see anything in server2003 winlogon related to this server, maybe it's in another thing that winlogon is meant to load up.

>>78552508
Also as you can see there, it's contacting the server at cszRPCEndPoint
...and looking up what that is
>static LPWSTR cszRPCEndPoint = L"IUserProfile"; // Do not change this name, SENS will use it as an endpoint to winlogon
Hm, maybe there is something in winlogon that's meant to start that...

>>78552528
https://l.wzm.me/_security/internet/_internet/WinServices/ch04s10s27.html
>In Windows Server 2003, three additional RPC service are supported inside winlogon.exe. These interfaces create the following endpoints:

>sclogonrpc LPC port
>IUserProfile LPC port
Ah fuck

File: never forget.png (20 KB, 604x217)

20 KB PNG

>>78547070
Our martyr.

>>78552534
I can't find anything in server2003 winlogon about that though, ugh
also that page says
>userenv.dll DLL RPC service
and has IUserProfile inside it, which sounds like userenv.dll is what handles it?

File: file.png (34 KB, 1144x314)

34 KB PNG

>>78552557
Aight I'm pretty sure userenv is the server for it, pic related.
This code is inside CUserProfile::Initialize, which gets called by InitializeUserProfile, which is the call we had to add to winlogon.
So I guess in amd64 either something changed in this function, or something changed which stopped winlogon from calling it. hm

>>78552658
Looking at amd64 winlogon now, InitializeUserProfile is called in 2 different places, vs 1 place in SP0 x86
Unfortunately don't have symbols for amd64 winlogon yet tho since wayback machine keeps cutting out at 100MB, does anyone know where I can find Windows2003_sp1.amd64.fre.rtm.symbols.exe ?

File: file.png (36 KB, 883x299)

36 KB PNG

>>78552777
Yeah the call to it is definitely different in SP1/amd64, pic related, SP1 amd64 on left, SP0 x86 on right.

userenv.dll!InitUserProfile call is changed to userenv.dll!ApplyGroupPolicy, instead calls InitUserProfile in 2 other functions, dunno what ones tho since I still can't get symbols downloaded ;_;

>>78552872
Should note that our codebase doesn't have userenv.dll!ApplyGroupPolicy with 0 params, instead there's a version with 5 params which I don't think userenv.dll exports, so it's looking like we might not be able to actually build a winlogon for SP1.

>>78552872
https://gofile.io/d/HEBX7N

>>78552956
Aha awesome, thanks.
Going afk for a bit to eat but I'll try seeing if we can add those new calls to our winlogon when I get back, can maybe make the ApplyGroupPolicy call via GetProcAddress too I guess

>>78552984
THANK YOU for keeping the project alive!

>>78552872
>>78552921
Quick look before I eat, seems I was wrong, with pdb loaded ApplyGroupPolicy magicly turned to InitUserProfile - I guess it got the function names from my systems userenv.dll which had different ordinals or some shit.
The InitUserProfile call looks mostly the same, the way that it sets g_Console might be a little different in amd64 though. I'll look into it after

>>78553113
Hm damn, doesn't seem like anything around that is different, afaik our amd64 winlogon should be calling InitUserProfile fine...

Buuut, maybe windows is having the same issue that I had with the function names. Ordinal in SP1 userenv.dll is different to ordinal inside our codebase, wrong function gets called instead of InitUserProfile, now it makes sense.

Could someone that's built amd64 winlogon upload the exe + pdb for it somewhere? pdb from symbols.pri\retail\exe would be preferable.

File: file.png (19 KB, 577x233)

19 KB PNG

>>78553601
wew

>>78553635
Anyone here that can test amd64 winlogon? I might have updated userenv.def that can let it use proper ordinals soon

>>78553747
sure

>>78553747
I can test when I am done tweaking my tool and at my main PC tomorrow morning if no one else has before then lol

>>78554012
Sweet, here, replace ds\security\gina\userenv\main\userenv.def with this, rebuild userenv folder under amd64, then build amd64 winlogon.
You'll only need the winlogon.exe that comes from it, this'll just make sure the userenv.lib that winlogon depends on has the right ordinals inside, which will then get put into the EXE.

https://gofile.io/d/aGK52T

Note that this will break winlogon on x86 SP0 unless you also copy userenv.dll to that too (and anything else that depends on userenv...)
Maybe there's a way we can have this as _sp1.def and only use it on amd64 builds...

Really there wasn't any reason for MS to change these ordinal numbers, doesn't seem that anything was added besides 2 functions that were placed at the end, I guess they changed it to stop people using the same cracked winlogon.exe on SP1? only reason I can think

>>78554012
>>78554022
I am not needed lol but will still test building AMD64 so I can incorporate it, at the moment it's limited to x86 building :(

>>78554043
If you do add amd64 support note that there's 1 missing amd64 lib needed to build: public\internal\windows\lib\amd64\usp10p.lib
Luckily XPSP1 tree has that exact lib for us, so we can just copy that over fine.

Should probably add that to the build guide ZIP really, it's the only main thing breaking amd64 builds I think

>>78554080
Good to know thanks, it shouldn't be an issue as it's essentially a wrapper for razzle

But worse case I could make it download the missing bits for AMD64 and place them, or use a locally extracted XPSP1 dir to find and copy over idk

>>78554028
BTW this could maybe be a part of why our amd64 setup crashes, if one of the prebuilt SP1/amd64 files has to import from userenv.dll, our userenv would have had the older ordinals inside, so those would have imported the wrong function = maybe crash, idk how winlogon didn't crash from importing wrong function though.

>>78554161
My guess is most likely Setup uses a different set of functions from the 'standard' purposes of Winlogon (Actual logon and login management etc) but beyond that I am not sure I have any idea

>>78554028
God damnit, spent the last 30 minutes now trying to find working x64 enterprise key, does anyone here know any?

>>78554628
wow, finally found one
Windows Server 2003 R2 Enterprise x64 Edition KK2WD-BFYJ6-77X87-8TRBF-9B343
this is for 5.2.3790.1830.srv03_sp1_rtm.050324-1447_amd64fre_server-enterprise_retail_en-us-ARMEXFPP_EN.iso

>>78554664
Interesting that an R2 SP1 key worked

File: easy-build-2.png (40 KB, 762x544)

40 KB PNG

Would someone be able to try Easy-Build on XP/Server '03 and 7?
I have only currently tested on 10 x86 + x64

Also need someone to double check that the switch from fre to chk and vice versa builds the selected type (I think I got them all, but razzle sets multiple variables depending on what type so a the SET output with razzle set vars loaded would be handy to compare)

https://github.com/Empyreal96/easy-build-nt5

File: 2020_11_05-22_47.webm (481 KB, 752x570)

481 KB WEBM

x64 report: login dialog still won't display for 3 minutes, after that I login and don't even see "preparing user profile" or whatever, dialog just disappears, then screen freezes and can't move mouse pointer, and finally I get BSOD.

This is different to what amd64 used to do right? It used to just redraw?
I'll install chk version and try debugging shit now. I get the feeling this is very related to the setup BSOD.

webm related too

File: file.png (3 KB, 509x62)

3 KB PNG

>>78554880
pic related is crash info, didn't look into windbg yet.
I think the issue is more ordinal shit, RPCRT4.dll has a bunch of changed ordinals, and NTDLL does too (which was apparently the faulting module here?)

Even if the export name is included in the export table it'll use the given ordinal to find it IIRC. When they released SP1x64 it was the first release of amd64 so they didn't need any backward compat, they could move ordinals how they liked.

File: file.png (8 KB, 751x64)

8 KB PNG

>>78555094
huh, I press ignore to this and it booted to desktop fine.
Maybe I should have tested a fre build instead lel

>>78555349
Guess there are different functions for fre and chk?

File: file.png (34 KB, 1260x210)

34 KB PNG

>>78555410
in fre that assert wouldn't have even been compiled in, and the crash wouldn't have happened. I'm kinda surprised an assert would make it crash out tho..

Think I found the difference, just one extra byte added to Buffer variable, so check became >= 0x11 instead of >= 0x10

File: ruby2.png (201 KB, 600x600)

201 KB PNG

>>78540416
I recommend you documenting everything now because it will be hell to do later.
I hope at least the anons who can build this have it automated.

>>78555466
Guess that was just enough for it to bug check, what does that assert refrence to?

File: .webm (1.6 MB, 796x598)

1.6 MB WEBM

Got usrenv.c updated, now chk build seems to be fine with windbg unattached, webm related (ignore the winlogon error report that shows up, that was from previous run), I'd really be interested to see amd64-setup-anon test this out.

There's still a 3-minute wait before logon dialog shows though.. gonna try looking into that and then hopefully have a new ZIP to post soon.

>>78555693
bugcheck will happen if anything makes winlogon close, so any tiny thing that makes it fall over will make it bsod really.

The assert is about some bug inside SetEnvironmentULong, win2000 had a buffer that snwprintf could overrun by 1 byte, win2003 SP0 increased buffer size + added shit so nothing can ever write to/past that byte, guess I didn't notice this function when I was matching shit with BinDiff.

>>78555851
That's interesting thanks for informing

>>78554028
Testeroo here - I built gina\userenv under amd64 and then built gina\winlogon and put both userenv.dll and winlogon.exe onto the amd64 sp1 retail vm - Upon boot I now get the 0x00000080 BSOD.

>>78556516
BSOD should only be after logging in, I guess copying userenv probably did that:
>You'll only need the winlogon.exe that comes from it
We're building userenv just for the .lib used during winlogon build, the dll itself shouldn't be used in an SP1 build since it'd probably break other shit

>>78556561
Damn, they changed ordinals inside msgina.dll which caused the 3 minute wait, surprised it didn't cause a crash too, but they were only shell-related things so probably didn't do much that could cause one I guess.

Here's updated winlogon pack, should build amd64 fine, make sure to read the readme about it.
I've only really tested amd64/chk, don't think anything x86 would have broken but not 100% sure. I did have to change some theming code a little, hopefully didn't break per-user themes or anything.

Would be interesting to see what this does with amd64 setup.

>winlogon200X_v3.zip
https://gofile.io/d/KkXXNq

>>78554796
>Would someone be able to try Easy-Build on XP/Server '03 and 7?
>I have only currently tested on 10 x86 + x64
>Also need someone to double check that the switch from fre to chk and vice versa builds the selected type (I think I got them all, but razzle sets multiple variables depending on what type so a the SET output with razzle set vars loaded would be handy to compare)
>https://github.com/Empyreal96/easy-build-nt5
Nice script buddy, thanks so much

Any updates on Sizzle?

>>78540416
Bump before going to sleep.

>>78556939
Glad you like it, thanks. Let me know if you use it and anything doesn't work lol

Currently working on being able to modify Timebomb with it..

Being able to change the output dir will be a pain to set up fo play nice with changing from fre to chk, but that is also on the list todo.

>>78556755
Sneaky Russian, least you managed to find what's causing the 3 minute wait, seems alot of winlogon oridinals are tied in with alot of the missing source/files..

Theming is whacked in XP/03 anyway, signing custom .msstyles that don't follow proper uxtheme conventions still load perfect

Secondary bumper signing off

>>78556755
Finally figured out the GPO issue I think, was just missing a call to SignalUserPolicyForegroundProcessingDone, without that it'd be stuck on WaitForUserPolicyForegroundProcessing forever.

>winlogon200X_v3a.zip
https://gofile.io/d/cyXHey

Would appreciate hearing back if anyone tries it out, maybe it only fixed amd64/chk for all I know.

File: winlogon17.png (658 KB, 803x762)

658 KB PNG

>>78556755
Using the latest built (v3) winlogon, here is my testing results:

x86 srckit fre:
The theme does not switch once the user logs on successfully. (stays with the theme set on the system account) - before this was not an issue.

amd64 sp1 retail fre:
Logon now works here! WOOT
log off on start menu shows "switch user" which does nothing because fast user switching / terminal services logon context is broken somehow).

amd64 srckit 1/4 installed: kernel boots, green windows 98 style desktop background color loads, mouse pointer loads up and hourglass pointer loads, os reboots. (no visible bsod) then vmware begins to complain about a processor error and the VM needs to be completely powered off to recover. - I strongly believe this is because of using missing sp1 retail level dll's and exe's in postbuild that we are missing in our srckit amd64 build. Still trying to investigate this.

General notes:
on both the x86 srckit vm and the amd64 sp1 retail vm, if you log in, open taskmgr (ctl+alt+del) go to the users tab you will not see anyone logged on. if you use the start menu and log off, you can log back on as the same user fine until you log off and log on as another user. Then if you look under task manager -> users on that user you will see two users logged on. if you log off and try to log back on as the original user you will get an error about the logon connect failing. - I will attach a screenshot showing both the theme issue as well as the logon-after-logon issues.

>>78557755
Testing now xD

>>78557755
v3a building under x86 fre yields the below error:
1>usrpro.c(1670) : error C4013: 'SignalUserPolicyForegroundProcessingDone' undefined; assuming extern returning int

This is after doing a bcz in "ds\security\gina" (gets the same error) then doing a bcz in "ds\security\gina\winlogon"

>>78557821
Same error on amd64 fre

>>78557758
>The theme does not switch once the user logs on successfully
hmm, any chance you can try replacing InitSystemParametersInfo inside envvar.c with one from v2d some time? Just copy-paste the whole function over it, that's the only function I changed related to theme stuff, was hoping I made it closer to RTM but maybe I broke it instead...

Glad to hear about amd64, so the setup has changed a little at least, could mean it is winlogon related but idk, I'd probably blame the SP1 stuff too, seems they messed with ordinals a lot in SP1 I guess to try preventing people mixing cracked files & stuff from RTM together, which is now what we have to do >.>

With setup did you do a full rebuild or just dirty build? The msgina/userenv ordinals change might need a full clean build to take effect (preferably with public\internal\ds\lib\amd64\msgina.lib & public\internal\ds\lib\amd64\userenv.lib deleted before building)

>>78557821
Oh fuck I forgot to copy the definition accros for that, at the top of usrpro.c at line 50 under the CheckForGPOScripts definition add

//
// 4chan: server2003 add, not exported in any headers?
//
USERENVAPI
DWORD
WINAPI
SignalUserPolicyForegroundProcessingDone();

Updated zip with that definition added

>winlogon200X_v3a1.zip
https://gofile.io/d/2mXnHH

>>78557844
On the setup vm I mounted the vm disk and swapped winlogon only. I will do anoter complete tree build though in a few.

>>78557869
Ahh right, it might work better if you copy msgina.dll & userenv.dll for that too, for our custom build copying those is fine since the rest of the code probably won't rely on any new SP1 things added, but in SP1 it's better to use the ones that's already there since they already have the right ordinals.

(even then there could be other DLLs that import from msgina.dll/userenv.dll which would need updated ordinals too, which is why I suggest clean build when using this, should let all the stuff we have code for get ordinals updated, hopefully there's nothing missing that also imports from it...)

>>78557844
Reverting InitSystemParameters inside envvar.c with v2d DID fix the theme system issue.

Also I notice that the user pictures are now working on the start menu as well as the logoff dialog being themed - tried to click switch user and that did nothing so then I clicked logoff and LOGONUI loaded AND WORKED! woot! (all this was on the x86 srckit vm)

>>78557993
Aha nice, guess I'll have to look into that function again.

Interesting about the other things, maybe it was the GPO stuff that fixed those.
So logonui works when you logoff, but it's still broken on startup?
There's a lot of Shell* functions msgina.dll exports which seem related to the logonui stuff, I added a few of them (which is what got us in trouble with this ordinal shit), but there's still a lot I still need to look into

>>78557864
Looks as though you can now connect to sessions (other than session Id 0) through taskmanager-> users - Session 0 gives the "The system cannot find the file specified. A new session will be created." error - I think this has something to do with named pipes. Not sure on that though.

>>78557993
Hm, any chance you can try out this version of InitSystemParameters? https://0bin.net/paste/CLV2Dy8c#lWIIWCIvKixFcBkp-mirRAC1WrG8Ae8Y1qMiJLE6dVy

File: winlogon18.png (65 KB, 805x806)

65 KB PNG

>>78558068

>>78558070
Ah shit 1 sec, this is still wrong

>>78558093
>>78558070
>>78557993
Hopefully this one should match with RTM properly: https://0bin.net/paste/H9z8i6fK#SxRRoWBxQ9EdHl4bBPynG5e-ptlUrF1oXEW3tuO6ZON

>>78558127
It also looks like on amd64 sp1 retail that there is never a console / terminal services session created except for ID 0 which seems to be hidden in taskmgr. so there can only ever be one user logged on at a time and those system cannot find the file specified errors never happen - logonui also never seems to appear.

All the VM's I am testing with are fre/pro sku btw.

>>78558147
Taht is to say that no additional terminal server sessions are ever created. it's only ever one user at a time on amd64 currently.

Testing the new initsystemparameters now.

>>78558127
Themes are still 'sticky' from the localsystem account with this version of the function.

>>78558216
Ah damn, that's weird, that was a near 1:1 with RTM, some things were inverted which I fixed here, but this will probably give the same effect: https://0bin.net/paste/4BD9j9L9#XU+-WYFHNDtC++Fhd4cn4VOFlewzo6lOi8SpNEw/e3Z

That one is 100% match with RTM's function, but maybe doing things the proper way RTM uses needs us to do something else first, still a lot of Shell* things I'm not using here...

BTW, does >>78558080 leave anything in event viewer at all?

>>78537660
>Compilable pseudo-sources of XP SP1 x86 winlogon
Having trouble compiling this, was there anything you changed besides ds folder that I need?
Here's build.log: https://0bin.net/paste/MxIcG+JE#sWbQ5gWGgGiUFNKgGoG+qe-OohI85NrvhltNQQgz9m6

>>78558256
localsystem theme still 'sticky' with this latest revision.

>>78558283
Yeah figured as much, thanks for making sure anyway.
Very strange. I'll have to look into the other Shell usages I guess.

If you want to try one more thing, replacing the if block underneath
>4chan todo: this weird ass if statement (probably uses goto or something...)
with

    if(bUserLoggedOn) {
        ShellNotifyThemeUserChange(ULT_LOGON, pWS->hToken);
    } else {
        ShellNotifyThemeUserChange(ULT_LOGOFF, pWS->hToken);
    }

could help us make sure that it's this if statement which is causing it, I'll probably look into messing with themes later/tomorrow and try some stuff with windbg attached.

>>78558256
Nah, nothing in the event log aside from the
"session disconnected from winstation" event id 683 after doing a right click and disconnect in taskmgr-> users.

I can logon and logoff many times in succession and as different users just fine until I do that disconnect in taskmgr. Then logonui shows the user I just disconnected from still logged in and NUM programs running but once I try to log back in as that user that is when the error dialogs start as if there is a named pipe that is not working correctly or something.

>>78558323
themes are still 'sticky' from localsystem with the latest InitSystemParametersInfo AND the updated if statement.

File: file.png (24 KB, 579x447)

24 KB PNG

>>78558360
Ahh, pic related might be why lol, note the comment at the top..
I'll look into this some more now

>>78558399
Huh weird, that should have worked, I guess the other function changes might be responsible.
Any chance you can try the opposite, older InitSystemParams with newer if statement?

>>78558420
by newer if statement I mean the one from >>78558256 btw

>>78558428
grabbed the code from 78558256 and replaced the conditional block like this:

//
// 4chan todo: this weird ass if statement (probably uses goto or something...)
//

/*
if ((!IsActiveConsoleSession() && bUserLoggedOn) ||
(UpdatePerUserSystemParameters(pWS->hToken, bUserLoggedOn != 0), bUserLoggedOn)) {
ShellNotifyThemeUserChange(ULT_LOGON, pWS->hToken);
} else {
ShellNotifyThemeUserChange(ULT_LOGOFF, pWS->hToken);
}
*/

if(bUserLoggedOn) {
ShellNotifyThemeUserChange(ULT_LOGON, pWS->hToken);
} else {
ShellNotifyThemeUserChange(ULT_LOGOFF, pWS->hToken);
}

testing now.

>>78558562
still sticky themes from localsystem.

>>78540836
Bro you need to enter using http no with https

>>78558562
>>78558591
Ah crap I meant using the code from v2d with the new if statement from >>78558428
Since it seems it might be the code around it responsible, if the older if still isn't working

>>78558625
Confuzd ;p

v2d works well and the theme set on the localsystem account does not 'stick' after a logon and conversely the users theme does not stick after a logoff. Anything newer than v2d with or without

if(bUserLoggedOn) {
ShellNotifyThemeUserChange(ULT_LOGON, pWS->hToken);
} else {
ShellNotifyThemeUserChange(ULT_LOGOFF, pWS->hToken);
}

sticks the theme from localsystem (user theme never loads after logon).

Also logonui seems to only be being invoked / used on x86 builds for whatever reason.

>>78558653
What I mean for clarity is if I take the latest greatest pack code and revert that function to v2d themes work well. any copy of that function newer than v2d makes localsystem account themes 'sticky'

>>78558664
>>78558653
Hmm, so you've tried reverting to v2d and using the new if statement, like

if ((!IsActiveConsoleSession() && bUserLoggedOn) ||
(UpdatePerUserSystemParameters(pWS->hToken, bUserLoggedOn != 0), bUserLoggedOn)) {
ShellNotifyThemeUserChange(ULT_LOGON, pWS->hToken);
} else {
ShellNotifyThemeUserChange(ULT_LOGOFF, pWS->hToken);
}

and that works fine?
pretty strange, I'll need to look into that function some more I guess.

Anyway I've fleshed out some more of the SESSION_DISCONNECTED code, it'll actually call back into gina now, hopefully gets further with things.

>winlogon200X_v3b.zip
https://gofile.io/d/LwFdnI

>>78558851
There's still a lot of stuff related to reconnecting not included though btw, so trying to connect back to a disconnected session will probably still be pretty fucked

>>78558851
taking v2d and updating the conditional to

if ((!IsActiveConsoleSession() && bUserLoggedOn) ||
(UpdatePerUserSystemParameters(pWS->hToken, bUserLoggedOn != 0), bUserLoggedOn)) {
ShellNotifyThemeUserChange(ULT_LOGON, pWS->hToken);
} else {
ShellNotifyThemeUserChange(ULT_LOGOFF, pWS->hToken);
}

DID work theme wise.

>>78558851
Using this v3b, the main thing I notice is we still have the console session re-connection issues after a disconnect from task manager and I do note that the users theme does apply correctly after doing a disconnect and reconnect on other terminal server sessions (disconnecting and reconnecting sessions with an ID higher than 0 work correctly AND the theme gets appled. The theme is still sticky from the localsystem account on initial logon to a user though without the v2d and conditional update in the v3b codebase.

morning bump

bump

I've been OOTL, are we able to build x64 builds now?

>>78559834
We've been able to build x64 for a while, but it wouldn't boot because of missing things like winlogon and others, recently winlogon code from win2000 was updated to work with win2003 though so hopefully our x64 build can make use of it.

bump

bump

Who that have better known of ntos can explain how the Zw*** functions works? I have only see the definition of those but I cannot find where they are implemented! Anyone know how that are handled?

>>78561433
They are not implemented at all. When you call Zw* function, you call Nt* equivalent function. There is no difference between them in usermode. In kernel mode they treat parameters in different way. When use Zw* in kernel mode, it treats all parameters safe and do not validate them.

>>78561433
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-nt-and-zw-versions-of-the-native-system-services-routines

>>78561553
So and how that mechanichism is implemented? at ink time ot when the exe i load the Zw are remapped to Nt?

>>78546475
Mindlessly parroting gaymer nonsense doesn't make your spyware OS usable.

>>78561707
>https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-nt-and-zw-versions-of-the-native-system-services-routines
In general I can't see where the syscall stuff is hanlded in the kernel.

Did anyone try the custom pidgen with new winlogon yet?

Apparently anti-wpa used to work fine with a patched pidgen to allow any key, so hopefully it's the same here.

>>78561751
Custom pidgen is here btw >>78242359 / https://archive.rebeccablacktech.com/g/thread/78212123/#78242359

Bump

What's left for us to do

>>78559989
Has anyone tried it yet

>>78558280
>https://0bin.net/paste/MxIcG+JE#sWbQ5gWGgGiUFNKgGoG+qe-OohI85NrvhltNQQgz9m6
Three errors QuickReboot, KernelDebuggerPresent, ReaderStates are from checked vs free build difference (I haven't yet tried the checked build): just copy QuickReboot() from 2k source (haven't checked, but should be ok), add "extern BOOL KernelDebuggerPresent;" to winlogon.h, and ReaderStates inside DebugLog() should be var_30.ReaderStates.

The rest are from XP vs 2k3 diff.

_WinStationNotifyLogon comes from public/internal/termsrv/inc/winsta.h and this is more tricky, there is a diff between XP and 2k3 here (people working on porting 2k winlogon, note this!). 2k3 added a last param BOOLEAN* pfIsRedirected; _WinStationNotifyLogon is called twice, one is decompiled, the other is currently in assembly; try to add a global var "BOOLEAN tmp", in C code add "&tmp" as a last var, in assembly code add "push offset tmp" at loc_102D51D right before "call IsAppServer" (parameters are pushed in right-to-left order, so the last parameter of the prototype comes first in the assembly).

SynchronizeWindows31FilesAndWindowsNTRegistry and QueryWindows31FilesMigration come from public/internal/base/inc/winbasep.h. Did they finally get removed in 2k3? Well, for now they can be safely commented out, SynchronizeWindows31... with 4 preceeding push-es, QueryWindows31... with 1 preceeding push.

bump

Just to know, all the code I will need is in the torrent?

>>78563336
Glowie

Bump

Bump

>>78564661

bump bump bump

>>78563336
Reading the fucking guide is too fucking difficult?

What exactly is the 'codebase' version and 'branch' for srv03rtm?

bump

File: peepoSad-pc.png (55 KB, 1124x685)

55 KB PNG

>>78564880
I wasnt sure, sorry

bump for the sims source code

>>78565812
Based me too
https://youtu.be/zC52jE60KjY

bump

>>78540416
>http://yotsuba7pverpfs5.onion/files/ down
help anons where do u get ur IDA for linux & windows from

bumpity boop

>>78567935
>https://wopen3qf3trpihet.onion
>It's up now
for me not

>>78567961
I had to not use https to go to the site, just the domian.onion, though it still connects using https.

>>78567990
I'm a different anon, but thanks. What imbecile is sending tor links with https?

>>78567990
>>78568035
oh, lol.

>>78568035
Np, not super savvy on Tor, didn't know if that's an actual issue, seems it was lol.

>>78540416
>https://wopen3qf3trpihet.onion
>>78568035
OP apparently

The anon that is working on winlogon should post it on the hidden git.

bump

>>78568420
seconding, easier to keep track of the changes, i would do it but i only have v2c and v2d

>>78569534
btw git anon is based

Maybe this will help speed up the post build.
set HORSE_POWER=4
https://empyreal96.github.io/build-env-info/WIN2K3/tools/postbuild.txt

File: Screenshot_1.png (7 KB, 757x57)

7 KB PNG

Getting this weird issue, what's a way to fix it? it gets a fatal error, goes back to daytona, and tries building it all over again, resulting in an endless loop. What am I doing wrong?

>>78569562
Could be interesting if it is, especially on hw with more than 4 cores

>>78569645
I tried it, subjectively faster, but I still see 1 thread everywhere :)

>>78569681
Hmm maybe postbld threads are set inside the actual postbuild.cmd file rather than env variable

bump

Bump

Backup bump

I feel like a fucking dumbass, didn't turn off AV, now I gotta fucking unzip this shit again.
Remember to turn of antivirus when you start off x.x

bump

Bump

A big part of the problem with 64 bit builds is that there are files like this inside layout.inf / dosnet.inf / txtsetup.sif that have the wrong file names
w6to4svc.dll=55,,222222,,,,,82,0,0,6to4svc.dll
waaaamon.dll=55,,222222,,,,,82,0,0,aaaamon.dll

The actual file name being generated is on the right - the missing file name being expected by setup is on the left with the 'w' in front.

I been trying to get started in this. I downloaded the git from the .onion github for the x64 AMD (I'm using AMD Win 10 so that should be right). Reading the build-win2k3 and after running
"tools\razzle64.cmd free offline" I'm supposed to run
"tools\prebuild.cmd"
But it's not there? The first razzle command didn't throw any errors, but this is literally the first time I've tried building anything and I'm lost at this point. I did extract the x64 of win2003_prepatched_v9c over the .onion git btw.

>>78572645
Use nt5src.7z and patch with the prepatched zip instead of using the onion git. I found it works better.

>>78572811
That's actually what I wanted to do originally, but the nt5src.7z has two separate folders, should I extract the shit all together or do I use just the XPSP1?

>>78572848
You need some files from both, and you build in the Server 2003 tree. See the guide in OP. You put the 2003 files in

D:\srv03rtm

(Use the subst command to make the D: drive, run

subst /?

for help) and the XP files wherever you want, since you're not building in it. 2003 can make an XP image, so even if you want XP, you need 2003.

>>78573199
Ahh, do I need to do the subst if I'm literally running it all on the D drive.

bump

>>78540547
>You could work on ReactOS

https://github.com/reactos/reactos/blob/master/CONTRIBUTING.md
>Legal notice: If you have seen Microsoft Windows source code, your contribution won't be accepted because of potential copyright violation. Before contributing, you must affirm that the following is true:
>I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.

bump

>>78563076
Thanks for getting back to me, I'll have a look at it later, shouldn't be too difficult to get it building under 2k3 hopefully, if it comes to it I could always switch to XPSP1 to build I guess, really just trying to get a build I can load into IDA so I don't have to bother with the RTM one that has checker/encryption crap inside it anymore.

Also I'm guessing this means your disasm was based on the fre winlogon then? I've mostly been comparing against chk but I guess I can switch to fre instead.

>>78572439
IIRC someone posted fixed up layout.inf/dosnet/txtsetup files for amd64 a few threads back, I think it was only the generated inf files instead of the inx files that they originate from though.

>>78574906
link: >>78506477

>>78574906
>>78574934
Ideally we'd update the .inx files so that x86-only drivers are tagged properly, IIRC it's something like adding @i to the start of the line, not sure if there's any docs about what all the tags are though, but you can see some of them here

@@:@i!n:39 = "Driver Cache\i386"
@@:@a:39 = "Driver Cache\amd64"
@@:@m:39 = "Driver Cache\ia64"

Don't ask me what the !n is about though, maybe someone here knows more?

bump for winamp code

>>78575550
https://rbt.asia/g/thread/76038369/

>>78573232
No. subst makes a mount point of sorts. You can turn, for example,

C:\NTSRC\srv03rtm

into

D:\srv03rtm

, just as an example.

>>78574341
Well, you could have worked on ReactOS, if you hadn't started working on this one.
Now happy with the sentence?
Let's just hope it's worth it.

>>78568420
yes.

bump

bump

>>78575717
>>78548386
>>78540547
ROS PR manager detected.

>>78540416
I'm thinking of adding a 'patcher' to the Easy-Build script, is it okay to let it download the prepatched archive when needed? (If you're not the prepatched anon then my bad lol)

>>78577601
Prepatched anon here, sure I don't mind.
If there's some way it could check the page for the latest ZIP that'd be nice, but I guess doing that would probably need it to handle gofiles/anonfiles/anonymousfiles somehow...
If that's too much work don't worry about it, you can rehost it somewhere easier if you like. I don't really expect to be making many more updates now anyway (tho I might make one more soon, just to add in the missing amd64 lib)

>>78577712
Cool thanks!
I did try tests with Gofiles but it threw a wobbly with the http security type.. For now I was thinking of hosting it on a seperate repo with files renamed easier for the script (e.g patcher-file1.patch) and the c# downloader saves it as a working .zip, then extract etc

As for latest version issue it would take me seconds to update it so I guess I wont worry for now.

With the missing files I may do the same kind of thing..

>>78558851
If it's okay with winlogon anon, I will do the same for the winlogon source

bump

>>78571488
>turning AV off
is defender a problem too ?

>>78578811
Yes. Any AV will interfere with high file IO loads, exactly what happens when you compile a big project like this one.

>>78578879
alright, but I can assume that if defender hasn't reported anything after I unzipped the source, then nothing happened

>>78578926
Main culprit is usually any 'Real-Time' protection as it's aim is usually to scan any files being processed in any ways

So if your AV has any protection like that, disable temporarily

Bump

>>78577810
>If it's okay with winlogon anon, I will do the same for the winlogon source
Go ahead, but remember that it's still very WIP and likely not very stable, you might want to add some warnings about it.

>>78580111
Don't worry I was going to, same with x64 support when I work on supporting that

Guide/zip v10 soon, testing out moyefi's recompiled 16-bit builds tools now, then gonna try adding fixes for building amd64, if all goes well it'll likely be the final guide/zip update.

Any amd64 builders remember what they needed to do to make amd64 build? IIRC it should just be copying
>public\internal\windows\lib\amd64\usp10p.lib
from XPSP1 into srv03rtm, right?

I might need to add amd64 parse.obj for directui too I guess, or edit dirs file to make it i386 only.

>>78578811
>>78578879
Win defender deleted "multimedia\danim\src\javacab\x86\cabcopy.exe" (but it was from the .onion github, no idea if it matters).

>>78580389
Looking forward to it!

>>78580389
Ah shit, just remembered that amd64 also needs systime.c/exinit.c too, since we don't have .obj for those...

I would include our recreations but I'm still not sure about how stable they are, including those would force x86 builds to use them even though we have .obj files for them...

Guess I can just add instructions about using the recreated ones when building amd64.

>>78580808
Hm actually, if i386 systime.obj/exinit.obj is set read-only, would it even try compiling any systime.c that's there?
Guess I'll have to experiment a little.

>>78580828
They are available in WRK and they should just work.

>>78581019
Hmm, that anon who keeps getting angry at us for mixing WRK stuff kinda turned me off using anything from there though.. (I also noticed WRK i386 version had quite a few differences from the i386 ones that were in this leak, they probably changed a few things in SP1 I guess)

Think I'll just build the systime.c/exinit.c from >>78506477 pack and include the .obj files that come from it, I'll probably include the source files too but renamed so that i386 will still use original .obj files.

Really hope we'll see systime.c/exinit.c fully matching some day, kinda surprised we got winlogon working before we got a proper systime replacement...

File: file.png (244 KB, 1371x966)

244 KB PNG

>>78578926
You can exclude the build folder in AV, like this in Windows 10 for Microsoft Defender, without having to disable it completely. Start by searching for "Virus & Thread Protection" in the start menu, follow the instructions in the screenshot, and add the build folder

Ah fuck, amd64 build almost finished without errors, except I got these two warnings since I was testing pre-compiled amd64 exinit.obj, and that ended up breaking ntoskrnl.exe build.

Strange, it never complained when we build with the prebuilt i386 exinit.obj/systime.obj files, what could be different about those?

I guess I'll add something so this warning can be skipped, if anyone knows how I can build exinit.c/systime.c so the .obj doesn't give this error pls let me know..

1>ex.lib(exinit.obj) : warning LNK4206: precompiled type information not found; 'e:\srv03rtm\base\ntos\ex\up\obj\amd64\exp.obj' not linked or overwritten; linking object as if no debug info
4>ex.lib(exinit.obj) : warning LNK4206: precompiled type information not found; 'e:\srv03rtm\base\ntos\ex\mp\obj\amd64\exp.obj' not linked or overwritten; linking object as if no debug info

>>78582290
Hm, seems running cl manually without the precompiled header options works to prevent precomp crap being added to obj, lets see if that'll fix shit without me needing to hide warnings.

>>78582360
Also the obj sizes went up quite a bit without precompiled header stuff, ~41KB to ~144KB, kinda explains the size difference between the original x86 .obj files and our recreations .obj, but the x86 ones are still quite a bit larger though.

>>78582290
it looks like copywow64.cmd is not being called or ran correctly in postbuild.

Also anyone who used my amd64 missing files archive needs to not use that since the sp1 level exe's/dll's/sys's/drv's in there will cause you issues.

I got postbuild.err to look like this in my latest amd64 build incarnation after many hours of copying NON - executable junk from the amd64 sp1 retail disk then copying built files from the binaries.amd64fre and binaries.x86fre directories to the correct places. Still had to replace several of the disk related drivers with the sp1 ones and then edit layout.inf/dosnet.inf and txtsetup.sif to remove some dead files and drivers that we don't have and sp1 doesn't include. After all this i land at the 0x80 winlogon bsod before gui mode setup starts once again (when using the latest built winlogon) so something is making winlogon exit....

(cplocation.cmd) ERROR: No eligible cross platform machine found, exiting.
(cplocation.cmd) ERROR: No eligible cross platform machine found, exiting.
(copywow64.cmd) ERROR: CPLocation.cmd failed, exiting ...
(copytsc.cmd) ERROR: CPLocation.cmd failed, exiting ...
(drivercab.cmd) ERROR: cabinc.exe -t 8 -q 40 -p 80 d:\binaries.amd64fre\.\driver.cab d:\binaries.amd64fre\perm2dll.dll d:\binaries.amd64fre\perm3dd.dll d:\binaries.amd64fre\trid3d.dll d:\binaries.amd64fre\atidvag.dll failed (-1073741819).
(drivercab.cmd) ERROR: Replace failed for pro sku, file was d:\binaries.amd64fre\atidvag.dll,
(drivercab.cmd) ERROR: cab file was d:\binaries.amd64fre\.\driver.cab ...
(cdimage.cmd) ERROR: compdir /kelntsd /m:d:\binaries.amd64fre\congeal_scripts\copywowlist_w.lst d:\binaries.amd64fre\wowbins d:\binaries.amd64fre\pro\i386 failed (1).
(pbuild.cmd) ERROR: Errors encountered at this time, exiting.

>>78582933
Have you tried anything with windbg yet? I'm sure that could tell us something, though I'm not sure how we can set the debug flags for winlogon/msgina since we won't have win.ini yet (or is that created by the time it gets to gui setup?)

If you can upload a new missing archive I don't mind checking it out

>>78582989
I've ran windbg on the host and booted the kernel on the latest 1/4 installed system and it does attach properly unfortunately i am not the best with debugging stuff - I did notice this in txtsetup.sif btw.

SetupDebugOptions = "/debug /debugport=com1 /baudrate=115200"
OsLoadOptions = "/fastdetect /noguiboot /nodebug"
ForceScsi = 1
ForceDiskClass = 1
ForceCDRom = 1
Architecture = amd64

>>78583107
Ah nice, did that need the PRERELEASE flag thing for it to attach?
It probably won't give much output unless it's a chk build, but fre can still be debugged if you know where to set breakpoints and shit.

You could also mix things and use a chk winlogon with a fre build, if the debug flags for winlogon are set it should print stuff to windbg
>>78507238 are the changes it needs to win.ini, if we don't have a win.ini at setup stage we can probably just edit winlogon's debug.c so all the flags are set too

>>78583153
Also should probably use chk msgina.dll too since that can give some debug output as well

>>78583153
I have PRERELEASE SET. The main trick is to do an f8 before the kernel starts and select 'debugging mode' from the boot options.

File: file.png (93 KB, 1103x639)

93 KB PNG

Good shit, amd64-fre built without errors (using precompiled systime.obj/extime.obj based on our decompilation), + the recompiled 16-bit tools seem to be working across the whole tree without any problems
(I didn't change anything related to postbuild yet though, as >>78582933 says there's still many issues with that...)

Updated guide+ZIP to v10: https://rentry.co/build-win2k3

>win2003_prepatched_v10.zip
Download in the link above.

Changes:
>[x64] Replaced MS-DOS Player for some 16-bit tools with recompiled amd64 versions, provided by an anon in the threads (many thanks!), source available inside `_x64\tools\tools16\16_bit_build_tools_v2.zip`
>Added missing `public\internal\windows\lib\amd64\usp10p.lib` library needed for amd64 build, taken from XPSP1 tree.
>Added parse.obj to `windows\advcore\duser\directui\engine\parser\obj\amd64` & `objd` folder, extracted from amd64 `directui.lib` file.
>Added updated `base\ntos\ex\exp.h` & amd64 systime.obj/extime.obj files based on anon decompilations.
>Added `msgina_sp1.def` & `userenv_sp1.def` from the winlogon200X pack, these will make amd64 builds of msgina/userenv use the SP1 export ordinal numbers, improving compatibility with SP1 winlogon & possibly other SP1 files.

Would appreciate it if some anons can try out x86/amd64 builds and make sure I didn't break anything (use "win64 amd64" in razzle parameters to build amd64 - note that postbuild/layout.inx/txtsetup.inx/etc haven't been updated for amd64 tho!)

>>78583107
If you built amd64 using the msgina_sp1.def / userenv_sp1.def with updated ordinals you might be able to use SP1's winlogon instead of ours too, maybe worth a try

>>78583153

Here is what I get in windbg:
https://0bin.net/paste/JfIPeFEv#gzndHf5vV4XpDN0bRBB9e9C8nZT8e3RCWcOR8-K/PUg

>>78583325
Hmm, doesn't really say much unfortunately.
Any chance you can try building a chk winlogon and add that to your build?

If you edit debug.c and change the WinlogonInfoLevel line so it's
>DWORD WinlogonInfoLevel = 0xffffffff;
That should make it enable debug output for everything without needing win.ini change

>>78583391
Put those changes in work - This is the new windbg output with a chk winlogon.exe with that dword updated.

*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
Windows Server 2003 Kernel Version 3790 UP Free x64
Built by: 3790.srckit.201106-0401
Machine Name:
Kernel base = 0xfffff800`00800000 PsLoadedModuleList = 0xfffff800`008d8880
System Uptime: not available
00000098:0000009C Map64BitDlls: Unable to open section for \KnownDlls\kernel32.dll, error c000003a
00000098:0000009C Wow64LdrpInitialize: ProcessInit failed, error c000003a
00000098:0000009C Wow64LdrpInitialize: Calling NtTerminateProcess.

*** Fatal System Error: 0xc000021a
(0xFFFFFA800051C240,0x0000000000000080,0x0000000000000000,0x0000000000000000)


STOP: c000021a {Fatal System Error}
The Windows Logon Process system process terminated unexpectedly with a status of 0x00000080 (0x00000000 0x00000000).
The system has been shut down.
Break instruction exception - code 80000003 (first chance)

A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

Connected to Windows Server 2003 3790 x64 target at (Sat Nov 7 18:28:09.176 2020 (UTC - 5:00)), ptr64 TRUE
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
Loading Kernel Symbols
......................................................
Loading User Symbols

Loading unloaded module list
.....

>>78583611
ADDITIONAL_DEBUG_TEXT: Windows Logon Process

MODULE_NAME: nt

FAULTING_MODULE: fffff80000800000 nt

DEBUG_FLR_IMAGE_TIMESTAMP: 5fa51eb1

BUGCHECK_STR: 0xc000021a_80

DEFAULT_BUCKET_ID: DRIVER_FAULT

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff8000082de73 to fffff8000088fca0

STACK_TEXT:
fffffadf`901259a8 fffff800`0082de73 : fffffadf`9c296780 00000000`c000021a fffffadf`9a0ef700 00000000`00000000 : nt!DbgBreakPointWithStatus
fffffadf`901259b0 fffff800`0082ed5a : fffffadf`00000003 00000000`ffff0025 00000000`ffffffff 00000000`00000000 : nt!KeStackAttachProcess+0x283
fffffadf`90125a30 fffff800`0082f34c : 00000000`00000000 00000000`c000021a fffffadf`902458e0 fffff800`008e4ca0 : nt!KeStackAttachProcess+0x116a
fffffadf`90125e00 fffff800`00a2bfb1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx+0x1c
fffffadf`90125e40 fffff800`0087f21c : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000000 : nt!MmCreateMirror+0x4651
fffffadf`90125eb0 fffff800`009b949d : 00000000`00000000 00000000`00000000 00000000`00000000 00000001`00001f80 : nt!ExQueueWorkItem+0x1ec
fffffadf`90125f40 fffff800`0088f726 : 00000000`00000000 fffff800`0087f110 fffff800`009b9470 00000000`00000000 : nt!PsRemoveCreateThreadNotifyRoutine+0x29d
fffffadf`90125f70 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!ZwYieldExecution+0x14e6


STACK_COMMAND: kb

FOLLOWUP_IP:
nt!KeStackAttachProcess+283
fffff800`0082de73 e981000000 jmp nt!KeStackAttachProcess+0x309 (fffff800`0082def9)

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: nt!KeStackAttachProcess+283

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: ntoskrnl.exe

BUCKET_ID: WRONG_SYMBOLS

Followup: MachineOwner
---------

>>78583611
No difference? strange. hmm

Maybe try changing line 127 of debug.c instead, from
>if (Mask & WinlogonInfoLevel)
to
>if (true)

If there's still no output after this I can only guess winlogon isn't being started properly, which is maybe what those Wow64LdrpInitialize errors mean...

File: file.png (23 KB, 665x286)

23 KB PNG

>>78583678
>I can only guess winlogon isn't being started properly, which is maybe what those Wow64LdrpInitialize errors mean...
The error code 0x80 seems to agree with this too

>>78583700
>Wow64LdrpInitialize
https://wbenny.github.io/2018/11/04/wow64-internals.html

File: file.png (45 KB, 878x568)

45 KB PNG

>>78583611
Hm, you might want to try building smss as chk too, seems it'll send a lot of debug info out to kd/windbg

>>78583611
>>78583823
Also maybe edit base\subsys\sm\server\sminit.c and change
>#if SMP_SHOW_REGISTRY_DATA
to
>#if 1
with search+replace before building, should make it output even more

if wow64 is trying to launch winlogon, does that mean winlogon is 32 bit?

>>78583862
Good question, don't think it is tho, maybe it has to use some wow64 code before launching any exe and something there is messing up before it can finish

I've tried both the x86 and amd64 versions and the same thing happens FYI.

>>78584011
wait wut, setup is broken with x86 when using our winlogon?

>>78584011
If you can try the chk smss.exe that should tell us some more about what it's actually trying to load, for all we know the registry path it's using to get winlogon.exe path doesn't exist and it's just loading an empty string or something...

Really a whole chk build would probably tell us a lot if it's something wrong with process being created, I dunno if we can actually get a chk amd64 to work at all though...

>>78584018
I think you misread his post, but testing x86 setup with our custom winlogon might be a good idea, dunno if anyone tried that yet

>>78582933
Any chance you can upload your latest missing pack for amd64?

>>78584018

Nah I mean trying both the built x86 and amd64 winlogon exe's on this 1/4 installed BSOD amd64 gui installer build.

>>78584127
...amd64bro ?

Got build error in amd64 checked build runned with win64 amd64.
Here the errors:
https://gofile.io/d/cEYVDm

So I guess we miss some files and probably the last linking errors is due to missing lib.

Is it possible to upgrade the URT version bundled with the source?

>>78584860
Never mind I hadn't run a clean build by typo, I'm trying now again

>>78583857
Just completed a amd64 chk build
Doing the #if 1 deal causes this build error.

3>server\sminit.c(3079) : error C4013: 'SmpDumpQuery' undefined; assuming extern returning int

>>78585476
Ah you might need to search+replace inside smsrvp.h & smutil.c as well

>>78585522
>>78585476
Oh actually if you want you could revert the replacements and just change smsrvp.h
>#define SMP_SHOW_REGISTRY_DATA 0
to
>#define SMP_SHOW_REGISTRY_DATA 1
Didn't notice that before lol

>>78585535
Going to try that in a moment.

https://0bin.net/paste/C-uHHKPH#qqIP0HemjmCd0m6qUIW4oOA-pp9lXjv4pyRR5HXhrHO

^ latest windbg output with a chk smss.exe and winlogon.exe on here.

>>78585589
>SMSS: Initial command 'winlogon.exe' terminated when it wasn't supposed to.
Well at least we know it is trying to run the right filename.

I'm looking into Wow64LdrpInitialize some more, this comment seems to suggest that it does get used even for 64-bit EXEs

Run64IfContextIs64:

    Called early in Wow64LdrpInitialize.  This routine checks the initial
    64-bit CONTEXT record, and if it looks like the new thread should be run
    as 64-bit (ie. without emulation), then this routine runs the 64-bit
    CONTEXT and terminates the thread/process.  If the initial CONTEXT
    appears to be one that should be run as 32-bit, then it returns back to
    its caller, and the caller must convert the CONTEXT to 32-bit and
    simulate it.

Apparently \KnownDlls just refers to System32 folder, is the kernel32.dll file missing from there?

>>78585644
>Apparently \KnownDlls just refers to System32 folder, is the kernel32.dll file missing from there?
Messed up my post, this wasn't part of the comment

>>78585655
latest log with the SMSS logging working

https://0bin.net/paste/X0XBcIHL#VJPyQx3dAZwkzWWJLJYckL8Je6cOC1iPYrOTTISomBY

>>78585655
Kernel32.dll is present in the built iso image at:
D:\binaries.amd64fre\pro\amd64

it is also present on the 1/4 installed system at:
c:\windows\system32\kernel32.dll

>>78585694
well you would not even able to load windows without kernel32.dll is just say an important DLL.

>>78585694
it is also built from the source tree and not copied from sp1 retail and it is a pe64 dll.

>>78585694
Hmm, very strange that it can't find it, c000003a = STATUS_OBJECT_PATH_NOT_FOUND...

I guess it could be looking in syswow64 instead maybe? Is there a kernel32 there?

Looking at ldrinit.c there is a UseWOW64 variable it uses to start using the Wow64Ldr stuff, wonder if we could just use that to disable WOW64 for now

>>78585715
Actually looking at the new log, all the Wow64 stuff seems to happen way before it tries loading winlogon...
Also it seems some other exes do get loaded in fine before winlogon is too:
>SMSS: Loaded SubSystem( Debug = )
>SMSS: Loaded SubSystem( Windows = C:\WINDOWS\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,4608,768 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16 )
>SMSS: InitialCommand( winlogon.exe )
>SMSS: Initial command 'winlogon.exe' terminated when it wasn't supposed to.

Maybe winlogon is running but quits before it can even print anything to windbg, hm

Could you try editing winlogon.c, in WinMain function, add
>OutputDebugStringA("WINLOGON INIT!\n");
before the
>NtQuerySystemInformation
line?

That should make it print something pretty much right when it gets loaded, before it can do anything that should make it crash, should let us know for sure if it is actually being ran or not.

>>78585715
Board thinks i am posting spam...

https://0bin.net/paste/GBf8HskP#tbSHzmEmiqTbYl1+O0o9LwPPZBNegsauz82sl5nIaXC

>>78584860
I wanna update so do a clean buit fix all errors expect the first onw. To solve that you have to generate again the MIDL file that should be done by the build /cZP but I found this is not was the case. So I delete the file and than run build /0 on the file directory and than it compile fine. So this only happen if you had perform a amd64 build over a x86 build.

>>78585846
Huh, so it's building both x64 version in system32, and x86 inside syswow64.. so why is it complaining at all? It could be dllcache one I guess but I kinda doubt it...

Maybe will need to look at Map64BitDlls function some more.

I just get NTLDR not found when I try booting amd64 ISO, was there something missing from "missing_amd64_and_kernel_v1.7z" pack?

>>78585886
That pack is way obsolete and yes NTLDR will be missing along with tons of other stuff. To build amd64 (still not fully working) you need to open a razzle window and build in x86 mode and then when that is done, open another razzle window and build in amd64 mode then you have to mount the AB!PXFRE_EN disc and copy lots of NON-EXE/DLL/SYS/DRV files over from it, then you have to do lots of copying of DLL's/EXE's/SYS's/DRV's from the binaries.x86fre directory then the layout.inf, dosnet.inf and txtsetup.sif files have to be edited to remove some missing-non-existant even in retail builds files. then you have to copy back over some sp1 miniport / IDE drivers It is a big headache. Once you have done all this, you then land with the winlogon bsod when gui mode setup tries to start.

>>78585926
Also as noted earlier,
copywow64.cmd and cplocation.cmd and drivercab.cmd are not working correctly for postbuilding amd64 builds currently.

>>78585819
I put that on line 827 of winlogon.c and nada on the debugger output.

>>78585864
The odd part here is that I don't know where the kernel32.dll inside c:\windows\syswow64 is coming from, on the AB1PXFRE_EN sp1 retail disc, there is only one kernel32.dl_ and it is in amd64 on our built pro sku it's the same deal. so where is the 32 bit dll coming from that is getting stuck in c:\windows\syswow64?!?

>>78586098
There's a wkernel32.dl_ in i386 on my amd64 sp1 iso, iirc someone did mention they renamed things in the layout.inf to start with w: >>78572439

>>78586098
DUH, that's right it is coming from the binaries.x86fre build directory and being manually copied over to pro\i386 (i386 directory of the built and retail ISO's) as WKERNEL32.DL_ and layout.inf is expanding and renaming it to kernel32.dll and placing it in syswow64.

I had to manually copy these files over from the binaries.x86fre directory hours ago and apparently forgot that. (this is why there is no new missing file pack ATM)

>>78586040
Damn, I guess it must mean our winlogon isn't being ran after all, ugh
So strange that it's apparently running csrss.exe fine though.
Still not sure if the problem is with the exe or something up with our windows build.

Hm, since our winlogon does run under SP1, I wonder if it works during SP1 setup too, maybe worth replacing winlogon.ex_ on an SP1 iso and checking if setup gets the same problem? that should tell us if it is winlogon.exe fault or not.

It's getting late here now though, but I'll give it a try tomorrow if nobody else has by then.

>>78583862
no because you can manually remove wow64 and it still boots

new thread when

bump